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(57) Abstract: The invention concerns a method for loading an applet in a smart card (2a), using two loading programmes, a so-called 
In-loader (IL), stored in the card, and Off-loader, respectively. The invention is characterised in that two specific communication 
protocol layers are provided, one in a terminal (1) hosting the card reader, the other in the card. Said layers include in particular 
intelligent agents enabling the card to provide a WEB client/server and a CGI gateway functional capability. The method comprises 
at least one step during which a HTTP request is sent to the card, to address a HTML page, a step which consists in retrieving pa- 
rameterising data transported by a HTML form and a step which consists in executing a second loading programme (TL) using the 
CGI functional capability to load the applet. 

(57) Abreg6 : L* invention conceme le chargement d'une "applet" dans une carte a puce (2a), a Taide de deux programmes de char- 
gement, dits "In-loader" (IL), stocke" dans la carte, et "Off-loader" (OL), respectivement. Selon Tinvention, on pr€voit deux couches 
protocolaires de communication specifiques, Tune dans un terminal (1) h6bergeant le lecteur de la carte, 1' autre dans la carte. Ces 
couches comprennent notarnment des agents intelligent^ permettant & la carte d'oflnr une fonctionnalite' de client/serveur "WEB" et 
de passerelle "CGI". Le proc£d6 comprend au moins une e*tape pendant laquelle une requete "HTTP" est envoyee a la carte, pour 
adresser une page "HTML", une gtape de recuperation de donnees de paramitrage v£hiculees par un formulaire "HTML" et une 
e'tape d'execution du second programme de chargement (IL), par mise en oeuvre de la fonctionnalite" "CGI", pour charge 1* "Applet". 
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En ce qui concerne les codes a deux lettres et autres abrevia- 
tions, se referer aux "Notes explicatives relatives aux codes et 
abreviations" figurant au debut de chaque numero ordinaire de 
la Gazette du PCX 
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PROCEDE DE CHARGEMENT D'UNE PIECE DE LOGICIEL DANS UNE 
CARTE A PUCE, NOTAMMENT DU TYPE DIT "APPLET" 

L'invention concerne un procede de chargement d'une piece de 
logiciel dans une carte a puce. 

Elle s'applique plus particulierement au chargement d'une piece de 
5 logiciel appelee en frangais "appliquette", plus connue sous le terme anglo- 
saxon d' "applet". II s'agit d'une application ecrite en langage "JAVA" 
(marque deposee). Ces applications, generalement peu volumineuses, sont 
independantes des architectures des systemes sur lesquelles elles sont 
implantees. Elles peuvent done fonctionner sur nlmporte quel systeme 

10 informatique, dans la mesure ou celui-ci implemente le concept dit de 
"machine virtuelle JAVA" ("Java Virtual Machine"). Une application ecrite en 
langage JAVA est en general traduite en un langage intermediate dit "Byte 
Code". La machine virtuelle JAVA precitee constitue un interpretateur de ce 
"Byte Code", de maniere a etre executee directement sur un systeme cible, 

15 hote de ladite machine virtuelle. 

Generalement, les architectures de systeme sur lesquelles tourne 
ce type duplications sont du type dit client-serveur. Dans ce cas, on parle 
egalement de "servlet" pour une application stockee sur un systeme serveur 
et "applet" pour une application stockee sur un systeme client. Dans ce qui 

20 suit, on utilisera le terme "applet" de fa?on generique. 

Des pieces de logiciel, se presentant sous la forme d* "applet" qui 
vient d'etre rappelee, dans la mesure ou la quantite de code n'est pas trop 
volumineuse, peuvent etre stockees dans une memoire non volatile presente 
sur une carte a puce, au meme titre que toute autre application. 

25 Aussi, le procede selon I'invention est plus particulierement 

concerne par un terminal ou station d'utilisateur muni d'un lecteur de carte a 
"puce". 
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Dans le cadre de I'invention, le terme "terminal" doit etre compris 
dans un sens general. Le terminal precite peut etre notamment constitu§ par 
un ordinateur personnel fonctionnant sous divers systemes d'exploitation, 
tels WINDOWS ou UNIX (tous deux etant des marques deposees). II peut 
5 etre aussi constitue par une station de travail, un ordinateur portable ou un 
terminal de carte dit dedte. 

Dans I'etat actuel de la technique, le chargement d'une "applet" sur 
une carte a puce (encore appele telechargement) se fait grace a deux 
programmes specifiques. Ces programmes sont generalement connus sous 
10 les termes anglo-saxons "Off-Loader", pour le premier, et "In-Loader", pour 
le second. Le programme "Off-Loader" s'execute sur le terminal et le 
programme "In-Loader" s'execute dans la carte a puce. Les programmes de 
chargement "Off-Loader" et "ln-Loader n communiquent entre eux au travers 
d'une liaison normalisee de type ISO 7816-3, protocole universellement 
15 retenu pour les communications entre une carte a puce et son terminal hote. 
Ce protocole met en oeuvre une suite d'echanges generalement 
proprietaires (commandes d'un type dit "APDU" qui seront explicitees ci- 
apres) afin de realiser le chargement d'une "applet". 

La figure 1A annexee a la presente description illustre de fagon 
20 schematique ^architecture mise en ceuvre pour le chargement d 1 "applets" 
dans une carte a puce selon Tart connu. 

Le terminal 1 stocke un premier programme specifique de 
chargement ("Off -Loader"), reference OL. II communique avec une carte £ 
puce 2, via un lecteur de carte a puce 3. Les transmissions s'effectuent selon 
25 un protocole de communication normalise, faisant appel aux commandes 
precipes, protocole qui sera detaille ci-apres. 

La carte a puce 2, pour sa part stocke un second programme 
sp6cifique de chargement ("In-Loader"), reference IL. 

Un premier inconvenient de ce proc§de est que les programmes IL 
30 et OL doivent etre apparies pour pouvoir communiquer entre eux. II s'ensuit 
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que s'ils sont d'origines differentes, ils ne sont pas, a priori, compatibles. 
Cette caracteristique est iiee au jeu de commandes a utiliser. 

Un deuxieme inconvenient est du au fait que les communications 
s'effectuent selon le protocole ISO 7816 precite. En effet, celui-ci impose une 
5 proximite physique entre les programmes OL et IL. II s'ensuit que le 
programme OL doit generalement s'exScuter directement sur le terminal 1 et 
non, par exemple, sur un autre terminal ou un serveur eloigne. 

Or, avec I'essor spectaculaire du reseau Internet, un nombre 
toujours croissant de terminaux sont connectes a ce reseau, notamment 
w pour pouvoir etre en liaison avec des serveurs eloignes, de type "WEB". II 
serait done interessant, par exemple, de pouvoir stocker la partie "Off- 
Loader" OL des programmes de chargement d' "applets" sur un serveur 
"WEB" connecte a ce reseau. Les "applets" a charger sur une ou plusieurs 
carte(s) a puce pourraient d'ailleurs etre aussi stockees sur ce serveur ou 
15 sur un ou plusieurs autres serveurs de ce type. 

Dans I'etat actuel de la technique, ce mode operatoire bute sur une 
double impossibility La premiere a deja ete evoquee : la norme retenue pour 
les communications entre le terminal et la carte a puce impose a priori une 
proximite physique entre la localisation des programmes "Off-Loader", OL, et 
20 "In-Loader", IL. 

D'autre part, les transmissions entre deux systemes, par exemple 
un terminal et un serveur eloigne, via le reseau Internet, font appel a des 
protocoles de type Internet. Dans Tetat actuel de la technique, il n*est pas 
possible de realiser des communications directes entre une carte a puce et 
25 le reseau Internet, comme il va I'etre explicite egalement. 

Dans le cadre de Hnvention, le terme "reseau Internet" englobe, 
outre le reseau Internet proprement dit, les reseaux prives d'entreprises ou 
similaires, du type dit "intranet", et les reseaux les prolongeant vers 
I'exterieur, du type dit "extranet", et de fa?on generate tout reseau dans 
30 lequel les echanges de donnees s'effectuent selon un protocole du type 
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Internet. Dans ce qui suit un tel reseau sera appele de fagon g6nerique 
"reseau Internet". 

On va tout d'abord rappeler brievement Parchitecture generale d'un 
systeme duplication a base de carte a puce, relie a un reseau Internet, par 
5 reference aux figures 1 B et 1 C. 

Un systeme duplication a base de carte a puce comporte 
generalement les elements principaux suivants : 
une carte a puce ; 

un systeme hote constituant le terminal precite ; 
10 - un reseau de communication, a savoir le reseau Internet dans 

['application preferee ; 

et un serveur d'application connect e au reseau Internet. 
La figure 1B illustre schematiquement un exemple d'architecture de 
ce type. Le terminal 1, par exemple un ordinateur individuel, comporte un 
75 lecteur 3 de carte a puce 2. Ce lecteur 3 peut etre ou non physiquement 
int§gr6 dans le terminal 1. La carte a puce 2 comporte un circuit integre 20 
dont des connexions d'entrees-sorties affleurent en surface de son support 
pour autoriser une alimentation en energie electrique et des communications 
avec le terminal 1. Ce dernier comprend des circuits d'acces 11 au reseau 
20 Internet/?/. Ces circuits peuvent etre constitues par un modem pour se 
connecter a une ligne telephonique commutee ou a une voie de 
communication a plus haut debit : reseau numerique a integration de 
services ("RNIS"), cable ou liaisons par satellite, etc. Les circuits 11 
permettent de se connecter au reseau Internet Rl, directement ou via un 
25 prestataire de services Internet ("Internet Service Provider" ou "ISP", selon la 
terminologie anglo-saxonne). On peut egalement avoir recours a un systeme 
intermediate tel qu'un "proxy" ou un systeme d'isolation dit "firewall" ("pare- 
feu" ou encore appele "garde barriere"). 

Le terminal 1 comprend naturellement tous les circuits et organes 
30 n§cessaires a son bon fonctionnement, et qui n'ont pas ete represents 
dans un but de simplification du dessin : unite centrale, memoires vive et 
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fixe, m6moire de masse a disque magn6tique, lecteur de disquette et/ou de 
Cede Rom, etc. 

Habituellement, le terminal 1 est aussi relie a des peripheriques 
classiques, integres ou non, tels un ecran de visualisation 5, un clavier 6a et 
5 une souris 6b, etc. 

Le terminal 1 peut etre mis en communication avec des serveurs ou 
tous systemes informatiques connectes au reseau Rl, dont un seul, 4, est 
illustre sur la figure 1A. Les circuits d'acces 11 mettent le terminal 1 en 
communication avec les serveurs 4 grace a un logiciel particulier 10, appel6 
w navigateur "WEB", ou "browser" selon la terminologie anglo-saxonne. Celui- 
ci permet d'acceder a diverses applications ou fichiers de donnees repartis 
sur I'ensemble du reseau Rl, generalement selon un mode "client-serveur". 

Habituellement, les communications sur les reseaux s'effectuent 
conformement a des protocoles repondant a des standards comprenant 
15 plusieurs couches logicielles superposees. Dans le cas d f un reseau Rl de 
type Internet, les communications s'effectuent selon des protocoles 
specifiques a ce type de communications, qui seront detailles ci-apres, mais 
qui comprennent egalement plusieurs couches logicielles. Le protocole de 
communication est choisi en fonction de Implication plus particulierement 
20 visee : interrogation de pages "WEB", transferts de fichiers, courrier 
electronique (e-mel, ou "e-mail" selon la terminologie anglo-saxonne), 
forums ou "news", etc. 

Uarchitecture logique du systeme comprenant un terminal, un 
lecteur de carte a puce et une carte a puce, est representee 
25 schematiquement par la figure 1C. Elle est decrite par la norme ISO 7816, 
qui elle-meme component plusieurs sous-ensembles : 

ISO 7816-1 et 7816-2, en ce qui concerne les dimensions et le 
marquage des cartes ; 

ISO 7816-3, en ce qui concerne le transfer! de donnees entre 
30 le terminal et la carte a puce ; et 
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ISO 7816-4, en ce qui concerne la structure du jeu d'ordres et 
le format des commandes. 

Sur la figure 1C, du cote terminal 1, on n'a represents que les 
couches repondant a la norme ISO 7816-3, referencees 101, et un 
5 gestionnaire d'ordres "APDU" (norme ISO 7816-4), reference 102. Du cote 
carte a puce 2, les couches repondant a la norme ISO 7816-3 sont 
referencees 200 et le gestionnaire d'ordres "ADPU" (norme ISO 7816-4) est 
reference 201 . Les applications sont referencees A<\ , .... Aj, A n ; n etant le 
nombre maximum duplications presentes sur la carte a puce 2. 

10 Une application, Aj, presente dans la carte a puce 2, dialogue avec 

le terminal 1 au moyen d'un jeu d'ordres. Ce jeu presente typiquement des 
ordres d'ecriture et des ordres de lecture. Le format des ordres est connu 
sous I'abreviation anglo-saxonne de "APDU" (pour "Application Protocol 
Data Unit"). II est defini par la norme ISO 7816-4 precitee. Une "APDU" de 

15 commande est notee "APDU. command" et une "APDU" de reponse est 
notee "APDU. response". Les "APDU" sont echangees entre le lecteur de 
carte et la carte a puce au moyen d'un protocole specifie par la norme ISO 
7816-3 precitee (par exemple en mode caractere : T=0 ; ou en mode bloc : 
T=1). 

20 Lorsque la carte a puce 2 inclut plusieurs applications distinctes, 

comme illustre sur la figure 1C, on parle de carte multi-applicative. 
Cependant, le terminal 1 ne dialogue qu'avec une seule application a la fois. 
Une application Aj se presente, par exemple, sous la forme d'une "applet" 
qui peut etre enregistree initialement, ou encore chargee a partir du terminal 

25 1. Pour ce faire, comme illustre par la figure 1A, on a recours a un 
programme "Off-Loader", OL, enregistre dans le terminal 1 et a un 
programme "In-Loader", IL, qui forme I'une des applications Aj de la carte a 
puce 2. 

La selection d'une application particuliere Aj est obtenue a I'aide 
30 d'une "APDU" du type selection ("SELECT"). Une fois ce choix effectue, les 



WO 01/59563 



PCT/FR01/00393 



7 

"APDU" qui le suivent sont achemines vers cette application. Une "APDU 
SELECT" nouvelle a pour effet d'abandonner I'application en cours et d'en 
choisir une autre. Le sous-ensemble logiciel gestionnaire des "APDU" 201 
permet de choisir une application particuliere A\ dans la carte a puce 2, de 
5 memoriser I'application ainsi choisie; et de transmettre et/ou recevoir des 
"APDU" vers et depuis cette application. 

En resume de ce qui vient d'etre decrit, la selection d'une 
application Aj et le dialogue avec celle-ci s'effectuent par echanges d'ordres 
"APDU". On suppose que les applications Aj sont des applications 

w conventionnelles, que Ton appellera ci-apres "GCA" (pour "Generic Card 
Application" ou application de carte generique). 

Ce mode operatoire explique que les programmes OL et IL doivent 
etre apparies, pour que les ordres "APDU" echanges puissent etre 
compatibles et compris par ces deux applications. 

15 Ces rappels etant effectues, il est a noter que la carte a puce 2 ne 

peut communiquer directement avec les navigateurs standards du 
commerce, sauf a modifier le code de ces derniers. 

En outre, et surtout, les cartes a puce actuelles, qui, par ailleurs sont 
conformes aux standards et normes rappeles ci-dessus, ont une 

20 configuration materielle et logicielle qui ne permet pas non plus de 
communiquer directement avec le r§seau Internet. En particulier, elles ne 
peuvent recevoir et transmettre des paquets de donnees, selon Tun ou 
Tautre des protocoles utilises sur ce type de reseau. II est done necessaire 
de prevoir une piece de logiciel additionnelle, implantee dans le terminal 1, 

25 generalement sous la forme de ce qui est appele un "plug-in", selon la 
terminologie anglo-saxonne. Cette piece de logiciel, qui porte la reference 12 
sur la figure 1B, effectue Tinterface entre le navigateur 10 et la carte 2, plus 
precisement les circuits electroniques 20 de cette carte 2. 
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^invention vise a pallier les inconvenients des procedes et 
dispositifs de Tart connu, et dont certains viennent d'etre rappeles, tout en 
repondant aux besoins qui se font sentir. 

Selon une premiere caracteristique de I'invention, les deux 
5 programmes de chargement, OL et IL ne sont plus dependants Tun de 
I'autre. En d'autres termes, ils n'ont plus a etre apparies pour etre 
compatibles. 

Selon une deuxieme caracteristique de I'invention, la partie OL des 
programmes de chargement n'a plus a etre stockee obligatoirement dans le 
w terminal, c'est-a-dire en relation de proximite physique avec la seconde 
partie IL. Tout au contraire, le programme OL peut etre stocke sur un 
serveur eloigne, connecte au terminal via un reseau de type Internet. 

Pour ce faire, et selon une autre caracteristique de Invention, la 
carte a puce se comporte comme un serveur/client de type "WEB" pour le 
15 terminal qui lui est associe. 

Pour atteindre ce but, on prevoit une couche de logiciel de 
communication specifique dans la carte a puce et son pendant dans le 
terminal. Le terme "specifique" doit etre entendu comme specifique au 
procede de Hnvention. En effet, ces couches de communications, dites 
20 specifiques, sont banalisees quelle que soit I'application consideree. Elles 
n'interviennent que dans le processus d'echanges de donnees 
bidirectionnels entre la carte a puce et le terminal, d'une part, et la carte a 
puce et le reseau, d'autre part. 

Les couches logicielles de communication specifiques comprennent 
25 notamment des composants logiciels, dits "agents intelligents", permettant 
en particulier des conversions de protocoles. Les agents intelligents seront 
appeles ci-apres plus simplement "agents". II existe des agents appareilles 
dans les couches de communication specifiques respectives associees au 
terminal et a la carte a puce. Selon le procede de I'invention, il s'etablit des 
30 sessions entre agents appareilles. 
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Selon une airre caracteristique, le procede de 1'invention rend 
possible factivation duplications de type conventionnel, c'est-a-dire du type 
"CGA" precite, localisees dans une carte a puce, sans devoir ies modifier en 
quoi que ce soit. 

5 Pour ce faire, on prevoit un ou plusieurs agents intelligents 

particuliers dits traducteurs de script, qui regoivent des requetes d'un 
navigateur et Ies traduisent en ordres "APDU" comprehensibies par 
Tapplication de type "CGA". De ce fait, on implante dans la carte a puce une 
fonction similaire a celle connue par ailleurs sous la denomination "CGI" 

w dans Ies serveurs "WEB" classiques. Cette fonction permet de mettre en 
oeuvre une application dans la carte a puce par un protocole Internet de type 
"HTTP". 

Le chargement d'une "applet" dans la carte a puce peut s'effectuer 
par cette interface "CGI". La partie IL du programme de chargement est 

15 considere comme etant un script de commandes, que Ton appellera "cgi- 
script", attache a la fonctionnalite serveur "WEB" offerte par la carte a puce. 
Les echanges entre Ies programmes OL et IL peuvent se derouler avec 
I'aide de formulaires classiques en langage "HTML" ou "forms" selon la 
terminologie anglo-saxonne. 

20 Tout en conservant les normes ISO precitees pour les 

communications entre terminal et carte a puce, via le lecteur de carte a 
puce, le procede selon invention permet des echanges entre les parties de 
programmes de chargement OL et IL en faisant appel au protocole de 
communication Internet "TCP/IP", la partie OL et les "applets" a charger 

25 pouvant etre stockees en local ou dans un serveur eloigne. 

^invention a done pour objet principal un procede de chargement 
d'une piece de logiciel dans une carte a puce a partir d'un terminal connecte 
a ladite carte a puce par I'intermediaire d'un lecteur de carte a puce 
permettant des communications selon un premier protocole determine, ledit 
30 chargement s'effectuant par la mise en ceuvre et la cooperation de premier 
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et second programmes de chargement, ledit second programme de 
chargement etant stocke dans ladite carte a puce, caracterise en ce qu'il 
comprend au moins les phases suivantes : 

aJ une premiere phase preliminaire consistant a implanter, dans 
ladite carte a puce, une premiere piece de logiciel, formant une couche 
protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal, une seconde piece de logiciel, formant une couche 
protocolaire de communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel comprennent 
en outre au moins une paire de premieres entites logicielles appariees, 
chacune desdites entites cooperant Tune avec I'autre de maniere a 
permettre I'etablissement d'une session d'echanges de donnees 
bidirectionnels entre au moins ledit terminal et ladite carte a puce, de 
maniere a ce que ladite carte a puce offre la fonctionnalite d'un client/serveur 
"WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce au moins une deuxieme entite logicielle, 
apte a interpreter une suite destructions et a la traduire en une suite 
d'ordres, de maniere a cooperer avec ladite seconde piece de logiciel 
specifique pour que ladite carte a puce offre une fonctionnalite d'interface 
passerelle dite "CGI", la dite carte a puce comprenant au moins une desdites 
suites destructions associee au dit second programme de chargement ; 
et en ce qu'il comprend au moins les etapes suivantes : 
1/ ouverture d'une premiere session d'echanges de donnees 

entre au moins ledit terminal et ladite carte a puce, pour la transmission 
d'une requete pour que ledit premier programme de chargement 
recupere des donnees de parametrage de chargement fournies par 
ledit second programme de chargement ; 
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21 ouverture d'une deuxieme session d'echanges de donn6es 

entre ladite carte a puce et au moins ledit terminal pour transmettre 
lesdites donnees de parametrage de chargement au dit premier 
programme de chargement, lesdites donnees de parametrage 
5 comportant une reference aux dites instructions associees au dit 

second programme de chargement ; et 

3/ ouverture d'une troisieme session d'echanges de donnees 
entre au moins ledit terminal et ladite carte a puce, pour la soumission d'un 
fichier de chargement prenant en compte lesdites donnees de parametrage 
10 de chargement, ledit fichier comprenant des donnees representant ladite 
piece de logiciel a charger; interpretation de ladite suite destructions 
associee au dit second programme de chargement, par mise en oeuvre de 
ladite fonctionnalit§ "CGI", de maniere generer une suite d'ordres transmise 
au dit second programme de chargement, a executer ce programme et a 
15 obtenir ledit dechargement de ladite piece de logiciel. 

^invention va maintenant etre decrite de fagon plus detaillee en se 
referant aux dessins annexes, parmi lesquels : 

la figure 1 A illustre schematiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
20 carte a puce selon Tart connu ; 

les figures 1B et 1C illustrent les architectures materielle et 
logique, respectivement, d'un exemple de systeme d'application a 
base de carte a puce connecte a un reseau Internet selon Tart 
connu, ; 

25 - la figure 2 illustre schematiquement un exemple de systeme 

d'application a base de carte a puce selon I'invention, cette derniere 
agissant en tant que client/serveur "WEB" ; 

la figure 3 est un diagramme d'etats d'une session entre des 
entites logicielles dites agents intelligents, selon un aspect de 

30 I'invention ; 
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la figure 4 illustre de fagon simplifiee ('architecture logique d'un 
systeme selon I'invention dans lequel la carte a puce comprend des 
agents intelligents ; 

la figure 5 illustre de fagon simplifiee ('architecture logique d'un 
systeme selon I'invention dans lesquels la carte a puce comprend 
des agents intelligents traducteurs de scripts ; 

la figure 6 illustre schematiquement un exemple de realisation 
d'une architecture permettant le chargement d'une "applet" dans une 
carte a puce selon I'invention ; 

- la figure 7 illustre la structure d'un fichier de chargement d'une 

"applet" pouvant etre en oeuvre par le procede selon Invention ; 
la figure 8 illustre schematiquement les phases principales du 

procede de chargement d'une "applet" dans une carte a puce selon 

un premier exemple de realisation pratique ; 

la figure 9 illustre schematiquement les phases principales du 

procede de chargement d'une "applet" dans une carte a puce selon 

un deuxieme exemple de realisation pratique ; 

les figures 9 et 10 illustrent deux exemples de formulaires en 

langage "HTML" utilisables par le procede de chargement d'une 

"applet" dans une carte a puce selon I'invention, pour la mise en 

oeuvre des methodes dites "GET" et "POST", respectivement ; et 
les figures 12A a 12G illustrent plusieurs variantes de 

realisation de realisation d'architectures de systemes permettant le 

chargement d'une "applet" dans une carte a puce selon I'invention. 

Dans ce qui suit, sans en limiter en quoi que ce soit la portee, on se 
placera ci-apres dans le cadre de I'application preferee de I'invention, sauf 
mention contraire, c'est-a-dire dans le cas d'un terminal connecte a un ou 
plusieurs serveurs eloignes via le reseau Internet. 

Avant de decrire le procede d'activation duplications localisees 
dans une carte a puce selon I'invention et de detainer une architecture pour 
sa mise en oeuvre, par reference a la figure 2, il apparait tout d'abord utile de 
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rappeler brievement les caracteristiques principales des protocoles de 
communication sur les reseaux. 

[-'architecture des reseaux de communication est decrite par 
diverses couches. A titre d'exemple, le standard "OSI" ("Open System 
5 Interconnection"), defini par P "ISO", comporte sept couches qui vont des 
couches dites basses (par exemple la couche dite "physique" qui concerne 
le support de transmission physique) aux couches dites hautes (par exemple 
la couche dite "d'application"), en passant par des couches intermediates, 
notamment la couche dite de "transport". Une couche donnee offre ses 

10 services a la couche qui lui est immediatement superieure et requiert de la 
couche qui lui immediatement inferieure d'autres services, via des interfaces 
appropriees. Les couches communiquent a I'aide de primitives. Elles 
peuvent egalement communiquer avec des couches de meme niveau. Dans 
certaines architectures, plusieurs couches peuvent etre inexistantes. 

15 Dans un environnement de type Internet, les couches sont au 

nombre de cinq, et de fagon plus precise, en allant de la couche superieure 
a la couche inferieure : la couche dite d'application ("http", "ftp", "e-mail", 
etc.), la couche dite de transport ("TCP"), la couche dite d'adressage de 
reseau ("IP"), la couche dite de liens de donnees ("PPP", "Slip", etc.) et la 

20 couche dite physique. 

Si on se reporte de nouveau a la figure 2, a I'exception de couches 
logicielles de protocole de communication specifiques, r6ferencees 13 et 
23a, respectivement implantees dans le terminal 1 et la carte a puce 2a, les 
autres elements, materiels ou logiciels, sont communs a Tart connu, et il n'y 

25 a pas lieu de les re-decrire de fagon detaillee. 

Le terminal 1 comprend des circuits 11 d'acces au reseau Rl, 
constitues par exemple d'un modem. Ces circuits regroupent les couches 
logicielles inferieures, Ci et C2, qui correspondent aux couches "physique" 
et de "lien de donnees". 
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On a egalement represents les couches superieures, C3 et C4, qui 
correspondent aux couches "d'adressage de reseau" ("IP", dans le cas 
d'lnternet) et de "transport" ("TCP"). La couche superieure duplication 
("http", "ftp", "e-mail", etc.) n'a pas ete representee. 
5 Uinterface entre les couches inferieures, C1 et C2, et les couches 

superieures, C3 et C4, est constitute par une couche logicielle 
generalement appelee "driver couches basses". Les couches superieures, 
C3 et C4, s'appuient sur cette interface et sont mises en ceuvre par 
I'intermediaire de bibliotheques de fonctions specifiques ou bibliotheques 
10 reseau 14, avec lesquelles elies correspondent. Dans le cas du reseau 
Internet, "TCP/IP" est mis en oeuvre au moyen de bibliotheques dites de 
"sockets". 

Cette organisation permet a un navigateur 1 0 de poser des requetes 
vers un serveur 4, pour la consultation de pages "WEB" (protocole "HTTP"), 

15 pour le transfert de fichiers (protocole "FTP") ou renvoi de courrier 
electronique (protocole "e-mail"), ce de fagon tout a fait classique en soL 

Le terminal 1 comprend egalement un lecteur de carte 3, integre ou 
non. Pour communiquer avec la carte a puce 2a, le lecteur de carte 30 
englobe egalement deux couches basses, CC1 (couche physique) et CC2 

20 (couche de lien de donnees), jouant un role similaire aux couches C1 et C2. 
Les interfaces logicielles avec les couches CC1 et CC2 sont decrites, par 
exemple, par la specification "PC/SC" ("part 6, service provider"). Les 
couches elles-memes, CC1 et CC2, sont notamment decrites par les normes 
ISO 7816-1 a 7816-4, comme il a ete rappele. 

25 Une couche logicielle supplemental 16 forme interface entre les 

couches applicatives (non representees) et les couches inferieures, CC1 et 
CC2. La fonction principale devolue a cette couche 16 est une fonction de 
multiplexage/demultiplexage. 

Les communications avec la carte a puce 2a s'effectuent selon un 

30 paradigme similaire a celui utilise pour la manipulation de fichiers dans un 
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j> 

systeme Sexploitation du type "UNIX" (marque deposee) : OUVRIR 
("OPEN"), LIRE ("READ"), ECRIRE ("WRITE"), FERMER ("CLOSE"), etc. 

Du cote de la carte a puce 2a, on retrouve une organisation 
similaire, a savoir la presence de deux couches basses, referencees CCai 
5 (couche physique) et CCa2 (couche de lien de donnees), ainsi qu'une 
couche d'interface 26a, tout a fait similaire a la couche 1 6. 

Selon une premiere caracteristique de I'invention, on prevoit, de part 
et d'autre, c'est-a-dire dans le terminal 1 et dans la carte a puce 2a, deux 
couches de protocoles specifiques : 13 et 23a, respectivement. 
w Dans le terminal 1, la couche specifique 13 s'interface aux "drivers 

couches basses" 15, aux bibliotheques 14 des couches reseau, C3 et C4, et 
aux couches protocolaires du lecteur de carte 3, c'est-a-dire les couches 
inferieures, CC1 et CC2, via la couche de multiplexage 16. La couche 
specifique 13 permet le transfert de paquets reseaux de et vers la carte a 
15 puce 2a. En outre, elle adapte les applications existantes telles le navigateur 
Internet 10, le courrier electronique, etc., pour des utilisations mettant en 
oeuvre la carte a puce 2a. 

Du cote de la carte a puce 2a, on retrouve une organisation tout a 
fait similaire constitute par une instance supplemental de la couche 
20 specifique, referencee 23a, pendant de la couche 13. 

De fagon plus precise, les couches specifiques, 13 et 23a, sont 
subdivisees en trois elements logiciels principaux : 

un module, 130 ou 230a, de transfert de blocs deformations 
entre les couches 13 et 23a, via les couches conventionnelles CC1, CC2, 
25 CCai et CCa2 ; 

une ou plusieurs pieces de logiciel, dites "agents intelligents", 
132 ou 232a, qui realisent, par exemple, des fonctions de conversion de 
protocoles ; 
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et un module de gestion de la configuration specifique, 131 et 
231a, respectivement ; module qui peut etre assimile a un agent intelligent 
particulier. 

Pour simplifier, on appellera ci-apres les agents intelligents, 
5 "agents", comme il a ete precedemment indique. 

On retrouve done, dans le terminal 1 et la carte a puce 2a, une pile 
protocolaire de communication entre les deux entites. 

Les couches de niveau deux (couches de lien de donnees), CC2 et 
CCa2, assurent I'echange entre la carte a puce 2a et le terminal 1. Ces 
10 couches sont responsables de la detection et I'eventuelle correction 
d'erreurs de transmission. Differents protocoles sont utiiisables, et a titre 
d'exemples non exhaustifs les suivants : 

la recommandation ETSI GSM 11.11 ; 

le protocole defini par la norme ISO 7816-3, en mode caractere 

15 T=0 ; 

le protocole defini par la norme ISO 7816-3, en mode bloc T=1 

> 

ou le protocole defini par la norme ISO 3309, en mode trame 
"HDLC" (pour "High-Level Data Link Control procedure" ou procedure de 
20 commande de liaison a haut niveau). 

Dans le cadre de I'invention, on utilisera de preference le protocole 
ISO 7816-3, en mode bloc. 

De fagon connue en soi, a chaque couche de protocole, il est 
associe un certain nombre de primitives qui permettent les echanges de 
25 donnees entre couches de meme niveau et d'une couche a I'autre. A titre 
d'exemple, les primitives associees a la couche de niveau deux sont du type 
"demande de donnees" ("Data.request") et "envoi de donnees" par la carte 
{"Data.response"), ainsi que "confirmation de donnees" ("Data.confirm"), etc. 
De fagon plus specifique, les couches 13 et 23a sont chargees du 
30 dialogue entre la carte a puce 2a et mote, e'est-a-dire le terminal 1. Ces 



WO 01/59563 PCT/FR01/00393 

17 

couches permettent lechange d'informations entre un utilisateur (non 
represents) du terminal 1 et la carte a puce 2a, par exemple via des menus 
deroulants sous la forme d'hypertexte au format "HTML". Elles permettent 
aussi la mise en place d'une configuration adaptee pour remission et/ou la 
5 reception de paquets de donnees. 

Comme il a ete indique ci-dessus, les couches comprennent trois 
entites distinctes. 

La premiere couche, 130 ou 230a, est essentiellement constitute 
par un multiplexeur logiciel. Elle permet I'echange d'informations entre la 
10 carte a puce 2a et le terminal hote 1 , sous la forme d'unites de donnees de 
protocole. Elle joue un role similaire a celui d'un commutateur de paquets de 
donnees. Ces unites sont emises ou regues via la couche de niveau deux 
(couche de liens de donnees). Ce protocole particulier de communication 
permet de mettre en communications au moins une paire d' "agents". Le 
15 premier agent de chaque paire, 132, est situe dans la couche 13, cote 
terminal 1, le second, 232a, est situe dans la couche 23a, cote carte a puce 
2a. Une liaison entre deux "agents" est associee a une session, que I'on 
pourra appeler "S-Agenf\ Une session est un echange de donnees 
bidirectionnel entre ces deux agents. Si Tune ou I'autre des couches, 13 et 
20 23a, comporte plusieurs agents, les agents d'une meme couche peuvent 
aussi etablir de sessions entre eux et/ou avec les modules 131 et 231a, qui 
constituent des agents particuliers. 

De fagon plus precise, un agent est une entite logicielle autonome 
qui peut realiser tout ou partie de fonctions des couches de niveau trois et 
25 quatre, en fonction de la configuration mise en oeuvre par le terminal 1 . 

Les agents sont associes a des proprietes ou attributs particuliers. 
Pour fixer les id§es, et a titre d'exemple non limitatif, les six proprietes 
suivantes sont associees aux agents : 

"hote" : agent localise dans le terminal ; 
30 - "carte" : agent localise dans la carte a puce ; 

"local" : agent ne communiquant pas avec le reseau ; 
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"reseau" : agent commimiquant avec le reseau (cote terminal) ; 
"client" : agent qui initialise une session ; 
"serveur" : agent qui regoit une demande de session. 
Un agent particulier est identifie par une reference, par exemple un 
5 nombre entier de 16 bits (c'est-a-dire compris entre 0 et 65535). Le bit de 
poids fort (b15 = 1) indique si la reference est locale (communications 
locales a la carte a puce ou au terminal) ou distante (b1 5 = 0). 

II existe deux grandes categories d'agents : les agents de type 
"serveur", qui sont identifies par une reference fixe, et les agents de type 
10 "client", qui sont identifies par une reference variable, que Ton peut qualifier 
d'ephemere, delivree par le module de gestion de configuration, 131 ou 
231a. 

Les agents communiquent entre eux a I'aide d'entite dites "unites de 
donnee de protocole" ou "pdu" (pour "protocol data unit", selon la 
15 terminologie anglo-saxonne) constituant une reference de destination et une 
reference de source. On pourrait egalement appeler cette "pdu" particuliere 
"SmartTP pdu", en reference au terme anglais "Smart Card" (carte a puce) 
couramment utilise. Les "pdu" utilisent notamment les references definies ci- 
dessus. 

20 Une "SmartTP pdu", ou plus simplement "pdu" ci-apres, comporte 

une reference source, une reference de destination, un ensemble de bits 
constituant des drapeaux ou "flags" qui precisent la nature de la "pdu", et 
des donnees optionnelles : 

- le drapeau "OPEN" (ouvert) est positionne pour indiquer I'ouverture 
25 d'une session ; 

- le drapeau "CLOSE" (ferme) indique la fermeture d'une session ; et 

- Le drapeau "BLOCK* (verrouille) indique que I'agent est en attente d'une 
reponse de son correspondant et suspend toute activite. 

On appellera jeton une "pdu" qui ne comporte pas de donnees. 
30 L'entite "SmartTP" controle I'existence de I'agent destinataire et 

realise la commutation d'un paquet vers ce dernier. 
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Une session agent "S-Agent" possede trois etats remarquables, a 

savoir : 

- un etat deconnecte : aucune session n'est ouverte avec un autre agent 

- un etat connecte : une session est ouverte avec un autre agent, une 
5 session "S-Agenr etant identifiee par une paire de references ; et 

- un etat bloque, Pagent etant connecte et attendant une reponse de son 
correspondant. 

Le mecanisme d'etablissement d'une session "S-Agent est le 

suivant : 

10 - une nouvelle instance d'un agent client est creee (cote carte a puce ou 
terminal), cet agent etant identifie par une reference ephemere pseudo- 
unique ; 

- Pagent client emet une "pdu" a destination d'un agent serveur (dont la 
reference est connue par ailleurs) avec le drapeau "OPEN" positionne et 

15 Pagent client passe a Tetat connecte ou bloque selon la valeur du drapeau 
"BLOCK" ; et 

- Pagent serveur regoit la "pdu" avec le drapeau "OPEN" et passe a Petat 
connecte 

Une fois une session ouverte, deux agents echangent des donnees 
20 via des "pdu", 

Le mecanisme de fermeture d'une session est le suivant : 

- un agent emet une "pdu" avec le drapeau "CLOSE 1 positionne (et 
qui comporte eventuellement des donnees ; et 

- Pautre agent regoit une "pdu" avec le drapeau "CLOSE 1 positionne 
25 (et qui comporte eventuellement des donnees) et la session "S-Agent" passe 

a Petat deconnecte. 

La figure 3 illustre de fagon schematique le diagramme d'etats des 
sessions "S-Agent", telles qu'elles viennent d'etre rappelees. 

Les couches 130 et 230a gerent des tables (non representees) qui 
30 contiennent la liste des agents presents, cote terminal bote 1 et carte a 
puce 2a. 
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De fagon pratique, les agents permettent d'echanger des donnees 
(de I'hypertexte, par exemple), mais egalement de declencher des 
transactions reseau, autorisant des communications entre la carte a puce 2a 
et un serveur eloigne 4 (figure 2). 

5 Les modules de gestion de configuration, 131 et231a, 

respectivement, sont assimilables a des agents particuliers. Par exemple, le 
module 131 , cote terminal hote 1 , gere notamment des informations relatives 
a la configuration de ce terminal (modes de fonctionnement), liste des autres 
agents presents, etc. Le module 231a, cote carte a puce 2a, a des fonctions 

10 analogues. Ces deux agents peuvent etre mis en communication Tun avec 
I'autre pour etablir une session. 

De fagon pratique, la carte a puce 2a est avantageusement 
"adressee" par utilisation d'une adresse "URL" (pour "Universal Resource 
Locator") definissant un rebouclage sur le terminal 1 lui-meme, et non un 

15 pointage sur un serveur externe. A titre d'exemple, la structure de cette 
"URL" est habituellement la suivante : 

http://1 27.0.0. 1:8080 (1), 
dans laquelle 127.0.0.1 est I'adresse "IP" de rebouclage et8080 est le 
numero de port. 

20 La figure 4 illustre de fagon simplifiee I'architecture logique d'un 

systeme selon invention du type represents sur la figure 2, mais represents 
de fagon plus detaillee. La carte a puce 2a comprend plusieurs agents, dont 
deux seulement ont ete represents : un agent de type non precisement 
defini 232ai et un agent 232a2, de type dit "WEB". La pile logique 

25 comprend, les couches de protocole inferieures, rSferencees 200a, 
repondant aux normes ISO 7816-3 (figure 2 : CCai et CCa2), le gestionnaire 
de commandes "APDU" 201ai, et le multiplexeur de paquets 230a, ce 
dernier etant interface aux agents, notamment Pagent "WEB" 231 a2 

Du cote terminal, il existe deux piles, Tune communiquant avec le 

30 reseau Internet Rl, I'autre avec la carte a puce 2a. La premiere pile 
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comprend les organes 11 (figure 2 : Ci et C2) d'acces au reseau (normes 
OSi 1 et 2) et les couches de protocoie "TCP/IP" (figure 2 : C3 et C4), 
referencees 1 00. Ces dernieres couches sont interfacees avec le navigateur 
"WEB" 10. L'autre pile comprend les couches de protocoie inferieures, 
5 referencees 101 , repondant aux normes ISO 7816-3 (figure 2 : C1 et C2>, le 
gestionnaire 102 d'ordres "APDU" et le multiplexer de paquets 130, ce 
dernier etant interface avec des agents, dont un seul 132, est represents Ce 
dernier, que Ton supposera de "type reseau", peut en outre communiquer, 
d'une part avec le navigateur 10, via les couches "TCP/IP" 101, d'autre part 

10 avec le reseau Internet Rl, via ces memes couches "TCP/IP" 101 et Porgane 
1 1 , d'acces au reseau Rl. 

Le gestionnaire d'ordres "APDU" 201a est egalement interface avec 
une ou plusieurs couches de niveau applications, que I'on appellera 
simplement applications. Ces applications, A u A t , A nt sont, comme il a 

15 ete indique, des applications de type conventionnel. 

En resume, la fonction client/serveur "WEB", fournie par la carte a 
puce 2a, peut etre realisee par I'association de I'agent "WEB" 232ai dans la 
carte a puce et de I'agent reseau 132 dans le terminal 1, et par la mise en 
oeuvre de sessions entre agents, comme il a ete decrit. 

20 La carte a puce 2a presente done bien la fonctionnalite 

client/serveur "WEB". En outre, selon une caracteristique du procede de 
Tinvention, nlmporte quelle application conventionnelle, A-\ a A n , du type 
"CGA" precite, peut etre activee au travers de ce client/serveur "WEB", soit 
par le navigateur "WEB" 10 present dans le terminal 1 , soit par un navigateur 

25 eloigne 4, localise en un point quelconque du reseau Internet Rl, par la mise 
en oeuvre de sessions entre agents. Selon le procede de ^invention, les 
applications, >Ai a A n , ne necessitent pas d'etre re-ecrites et sont mises en 
oeuvre telles quelles. 

Dans le cadre de ['invention, tout ou partie des applications A] a A n 

30 peut etre constitute par des "applets", chargees initialement dans une 
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memoire non volatile de la carte a puce 2 ou, au contraire, chargees par 
I'intermediaire des deux programmes de chargement OL et IL, dont on 
precisera ci-apres la nature et les lieux de stockage possible. 

Selon un autre aspect de ('invention, la fonction serveur "WEB" 
5 offerte par la carte a puce inclut un mecanisme similaire a la fonction dite 
"CGI" , (pour "Common Gateway Interface" ou "interface de passerelle") 
implantee dans les serveurs "WEB" classique. 

Avant de decrire un exemple d'architecture conforme a ('invention, 
permettant de realiser une fonction de ce type, au sein meme de la carte a 
10 puce, il est utile de rappeler les principles caracteristiques d'un mode de 
fonctionnement "CGI". 

Le "CGI" est une specification de mise en ceuvre, depuis un serveur 
"WEB", duplications ecrites pour les systemes d'exploitation "UNIX" 
(marque deposee), "DOS", ou "WINDOWS" (marque deposee). A titre 
15 d'exemple, pour le systeme d'exploitation "UNIX", la specification est 
"CGI 1.1" et pour le systeme d'exploitation "WINDOWS 95", la specification 
est "CGI 1.3". 

Toujours a titre d'exemple, une requete "HTTP" pour une adresse 
"URL", du type : 

20 "http://www.host.com/cgi-bin/xxx.cgi" (2), 

dans laquelle "host" se refere a un systeme hote (generalement eloigne), 
est interpretee par un serveur "WEB" comme ('execution d'un script de 
commande, de type "CGI" nomme "xxx" et present dans le repertoire "cgi- 
bin" de ce systeme hote. Bien que le nom du repertoire puisse etre a priori 

25 quelconque, par convention, c'est le nom donne au repertoire stockant les 
scripts de type "CGI". Un script est une suite destructions du systeme 
d'exploitation du systeme hote dont le resultat final est transmis au 
navigateur "WEB" emetteur de la requete precitee. Differents langages 
peuvent etre utilises pour ecrire ce script, par exemple le langage "PERL" 

30 (marque deposee). 
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De fagon pratique, la requete est habituellement affichee sur un 
ecran informatique sous la forme d'un formulaire compris dans une page 
"HTLM". Le langage "HTLM" permet de traduire un formulaire en une 
adresse "URL". Le formulaire comporte un ou plusieurs champs, obligatoires 

5 ou non, qui sont remplis par un utilisateur a Paide des moyens de saisie 
habituels : clavier pour le texte, souris pour les cases a cocher ou les 
boutons dits "radio", etc. Le contenu du formulaire (ainsi qu'eventuellement 
des informations et instructions dites "cachees") est emis a destination du 
serveur "WEB". Le code "HTLM" de la page decrit la structure materielle du 

w formulaire (cadre, graphisme, couleur, et tout autre attribut), ainsi que la 
structure des champs de donnees a saisir (nom, longueur, type de donnees, 
etc.). 

La transmission peut s'effectuer selon deux types de formats 
principaux. Un premier format utilise la methode dite "POST" et un second la 
15 methode dite "GET". Une information de type de format est presente dans le 
code de la page formulaire. 

Ce mecanisme n'est cependant pas directement transposable a une 
carte a puce, meme si celle-ci offre la fonctionnalite client/serveur "WEB" 
conformement a Tune des caracteristiques de ('invention. 
20 On va maintenant decrire un exemple d'architecture permettant 

d'activer une application quelconque, de type conventionnel, via un serveur 
"WEB" sur la carte a puce, par reference a la figure 5. 

Parmi les agents intelligents, conforme a Pun des aspects de 
Pinvention, on prevoit des agents intelligents particuliers, que Pon appellera 
25 ci-apres "Agents traducteurs de script" ou de fa?on abregee "ATS". Le script 
est alors interprets par un des agents intelligents. Cette traduction peut etre 
realisee de differentes manieres : 

a/ par Pagent "WEB" 232ai lui-meme, qui est dote dans ce cas d ? une 
double capacite ; 
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b/ par un agent script unique capable de traduire I'ensemble des scripts 
presents dans la carte a puce 2a ; 

ol par un agent de script dedie que Ton appellera M ATSD" ci-apres (un 
agent par script) ; ou 
5 d/ par un agent "APDU" 2010a du gestionnaire d'ordres "APDU" 201a, 
qui est dote, dans ce cas, d'une double capacite. 

L'agent "APDU" 2010a est une composante de la couche 
gestionnaire d'ordres "APDU" 201a. Cette derniere est une couche capable 
de centraliser tous les ordres "APDU" emis et/ou regus par le systeme, de 
w selectionner des applications, parmi A A a A n , mais egalement d'offrir une 
interface de type agent intelligent. Elle est done capable, selon Tune des 
caracteristiques de ('invention de communiquer avec tous les agents 
intelligents (via des sessions), que ces agents soient localises dans 
I'enceinte 6 ou la carte a puce 2a. 
15 Dans le cas ol ci-dessus, une session est ouverte entre I'agent 

"WEB" 232ai et Tun des agents "ATSD". 

La figure 5 illustre un exemple d'architecture pour laquelle les 
agents traducteurs sont du type "ATSD". lis sont references ATS, a ATS n et 
associes aux applications A^ a A n . ^application selectionnee etant supposee 
20 etre I'application A, la session s'etablit entre I'agent "WEB" 232ai et I'agent 
ATS. 

Un agent traducteur de script genere une suite d'ordres "APDU". 
Une session est ouverte entre I'agent traducteur, par exemple I'agent ATS r 
et I'agent "APDU" 2101a. Les ordres sont alors emis vers I'agent 
25 "APDU" 2101a. Le gestionnaire d'ordres "APDU" 210a selectionne 
I'application "CGA" A. et lui transmet les ordres "APDU", ordres traduits et 
done conventionnels, qu'elle est en mesure de , comprendre. Cette 
application est done correctement activee, sans avoir a la modifier ou a la 
rSecrire. 
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Les reponses de ['application A. sont transmises au gestionnaire 
d'ordres "APDU" 210a, a I'agent "APDU" 2010a, puis de nouveau a I'agent 
ATS. (et de fagon plus generate a I'agent traducteur de script). 

Les differents cheminements sont represents symboliquement sur 
5 la figure 5 par des traits pleins reliant les blocs fonctionnels, ou en pointilles 
a I'interieur de ces blocs. 

Le procede selon ('invention utilise les deux caracteristiques qui 
viennent d'etre rappelees : fonctionnement de la carte a puce en tant que 
serveur/client "WEB", incluant une fonction "cgi". Le chargement d'une 
w "applet" dans la carte a puce s^ffectue en effet via ('interface "CGI" offerte 
par celle-ci. 

De fagon plus precise, selon une caracteristique de I'invention, la 
partie de programme de chargement IL, localisee dans la carte a puce 2a, 
est constitute par un script. II s'agit, par exemple, d'un script associe a 

15 I'application referencee A. sur la figure 5. Ce script est, selon une 
caracteristique du procede de ('invention, active par une requete "HTTP", les 
echanges entre la partie OL et la partie IL s'effectuant selon le protocole de 
communication "TCP/IP". Les programmes IL et OL deviennent de ce fait a 
priori compatibles. En outre, il n'est plus necessaire que la proximite 

20 physique soit respectee, comme dans Tart connu (voir figure 1). La partie OL 
peut desormais etre localisee dans le terminal ou, de preference, dans un 
serveur eloigne (les liaisons entre le serveur et le terminal s'effectuant 
suivant ie protocole "TCP/IP"), voire, comme il le sera montre, etre stockee 
dans la carte a puce elle-meme. La requete "HTTP" precitee est initiee par la 

25 partie OL. 

II convient de remarquer que les donnees adressees a I'agent 
"WEB" 232ai sont transportees, de fagon conventionnelle en soi, sous 
formes d'ordres "APDU" destines a ('application particuliere constitute par le 
"Multiplexer de paquets" 230a. Le gestionnaire d'ordres "APDU" 201a 
30 selectionne cette application de maniere tout a fait similaire aux autres 
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applications de type H CGA", >Ai a A n , presentes dans la carte a puce 2a. En 
d'autres termes, le multiplexeur de paquets 230a est vu par le gestionnaire 
d r ordres "APDU" 201a comme une application n CGA" ordinaire. 

La requete "HTTP" est analysee par I'agent "WEB" 232ai qui 
5 detecte une reference a un repertoire particulier, que Ton appellera ci-apres 
par convention "cgi-smart" (par analogie a "cgi-bin"), d'une part, et a une 
application particuliere, IL dans le cas de I'exemple decrit. Le chemin 
complet est done, en I'occurrence "cgi-smart/il". 

Selon une caracteristique du procede de ('invention, I'entite "il" ci- 
w dessus designe un script particulier associe une application egalement 
particuliere (IL en I'occurrence). 

Une session est ouverte entre I'agent traducteur, par exemple 
I'agent ATS\ y et I'agent "APDU" 2010a. L'agent traducteur de script ATS\ 
genere une suite d'ordres "APDU". Les ordres sont emis vers I'agent 
15 "APDU" 2010a. Le gestionnaire d'ordres "APDU" 201a selectionne 
I'application "CGA'M/ (par exemple I'application IL) et lui transmet les ordres 
"APDU", ordres traduits et done conventionnels, qu'elle est en mesure de 
comprendre. Cette application est done correctement activee. 

La reponse de I'application IL (Aj) est transmise en sens inverse au 
20 gestionnaire d'ordres "APDU" 201a, a I'agent "APDU" 2010a, puis de 
nouveau a I'agent ATSj (et de fagon plus generale a I'agent traducteur de 
script). 

La reponse, constitute par un formulaire en langage "HTLM" 
reprend le chemin inverse, par la mise en oeuvre de sessions entre agents 
25 intelligents apparies, pour etre re-transmise au terminal 1 et, eventuellement 
a un serveur eloigne 4 (figure 4), via le reseau Internet Rl, pour atteindre 
finalement I'application OL. 

La figure 6 illustre schematiquement Tarchitecture logique 
permettant le chargement d'une "applet" selon le procede de I'invention. On 
30 retrouve sur ce schema les blocs materiels constitues par le terminal 1 , le 
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lecteur de carte a puce 3 et la carte & puce 2a, communiquant par mise en 
oeuvre du protocole normalise ISO 7816 precite et I'echange d'ordres 
"APDU", de maniere classique en soi. La partie OL est mise en relation avec 
la partie IL (sous forme d'un script reference ILs), par des echanges selon le 
5 protocole Internet "TCP/IP", de la maniere decrite precedemment, par mise 
en oeuvre des fonctions serveur "HTTP" (reference SC) et "CGI" de la carte a 
puce 2a. 

On doit bien comprendre que, bien que represents a I'exterieur de 
la carte a puce 2a pour des raisons de commodite, les blocs SC et ILs sont 
w constitues par differents modules internes de celle-ci, qui ont ete decrits par 
reference a la figure 5. 

Par contre, le programme OL n'est pas obligatoirement stocke dans 
le terminal 1 . 

On va maintenant detainer un premier exemple de chargement 
15 d'une "applet" dans une carte a puce 2a, par mise en oeuvre de la methode 
dite "GET". 

On suppose que le fichier de chargement de T "applet", reference 7, 
presente la structure illustree par la figure 7 : une entete 70, un corps 
principal 71 constitue par du "Byte Code" en langage "JAVA" et une 
20 signature electronique 72. Uentete represente un identifiant d'une application 
particuliere, genSralement appele "Application Identifier" ou simplement 
"AID". La signature electronique 72 est un mot chiffre avec une cle publique 
ou privee, obtenu a partir du code 71. Uensemble du fichier 7 peut 
egalement etre chiffre, pour des raisons de confidentialite, lorsqu'i! s'agit 
25 d'applications dites sensibles. Optionnellement, on peut prevoir une ou- 
plusieurs signature(s) electronique(s) supplementaire(s) non representee(s). 

Les principales etapes du processus sont illustrees 
schematiquement par la figure 8. 

Pendant une premiere etape, la partie de programme de 
30 chargement OL recupere, par une commande de type "GET", un formulaire 
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de chargement a partir de la carte a puce 2a, formulaire en langage "HTML" 
que Ton appellera arbitrairement "download.html". 

Cette recuperation est effectuee en consultant une page 
correspondante dont I'URL est typiquement de la forme suivante : 
5 http://1 27.0.0.1 :8080/download.html (3), 

dans laquelle http://127.0;0. 1:8080 est Tadresse URL de rebouclage 
proprement dite, telle qu'elle a ete definie par la relation (1), et 
"download.htmr la page "HTML" a obtenir. Cette requete met en oeuvre une 
session entre agents intelligents comme il a ete decrit en regard des figures 

10 2 a 4, selon un premier aspect de (Invention. La carte a puce 2a joue alors le 
role d'un serveur M WEB". 

La carte a puce 2a envoie le formulaire "download.htmr lors d'une 
deuxieme etape, toujours par ouvertures de sessions entre agents 
intelligents apparies, selon le procede de I'tnvention. Le formulaire obtenu 

15 peut etre affiche sur un ecran 5 par Pintermediaire du navigateur 10. 

Pour fixer les idees, un exemple d'un tel formulaire 8 est illustre par 
la figure 9. Outre diverses zones graphiques et de textes 80 (tjtre, etc.), le 
formulaire comprend des zones d'affichage pour Tentete 70 du fichier de 
chargement 7, le "Byte Code" 71 et la signature 72. La zone d'affichage 71 

20 est du type dit "TEXTAREA" en langage "HTML" et presente une facilite dite 
d* "ascenseur" pour I'affichage deroulant de textes longs. Les informations 
correspondantes, telles qu'elles apparaissent sur la figure 9, sont purement 
arbitraires. Enfin, on prevoit, de fa?on classique en soi, un bouton d'envoi 
"send", reference 81 , et un bouton de remise a zero "reset", reference 82. 

25 Ces boutons sont a la disposition d'un utilisateur du terminal (non 
represented Le bouton d^nvoi 81 permet de valider le formulaire et le 
retransmet a la carte a puce 2a ("soumettre le fichier de chargement" sur la 
figure 8) et le bouton de remise a zero 82 permet d'effacer les informations 
affichees et de re-initialiser le formulaire. 

30 Le code "HTML" necessaire pour programmer un tel formulaire est 

bien connu en soi et est a la portee de ITiomme de metier. II n'est pas 
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necessaire de le detaillor de nouveau. On peut cependant indiquer qu'il 
contient notamment une ligne de code en langage "HTML" qui se presente 
typiquement sous la forme : 

<form action= M http://1 27.0.01 :8080/cgi-smart/loader"> (4), 
5 dans laquelle http://1 27.0.01:8080 est I'URL de rebouclage de la relation (1), 
cgi-smart le repertoire "CGI" precite contenant le script de chargement 
"loader" que Ton a appele "il", script associe a la partie IL du programme de 
chargement. 

Si I'affichage visuel du formulaire 8 sur I'ecran 5 n'est pas souhaite 
10 (par exemple s'il n'y a pas d'operateur humain, les informations peuvent etre 
cachees incorporant le parametre "HTML" suivant : "TYPE=hidden" dans la 
ligne de code (4) precitee. 

Lors d'une troisieme etape, la partie OL envoie une requete "HTTP" 
de type "GET" a la carte a puce 2a, toujours par ouverture de sessions entre 
15 des agents intelligents apparies. En faisant appel a la fonction "CGI" offerte 
par la carte a puce 2a, telle qu'elle a ete decrite en regard de la figure 5, 
('application IL s'execute, le serveur "WEB" forme par la carte a puce 2a 
passant les parametres de la requete "HTTP" a cette derniere application. 

La requete precitee contient une ligne de code typiquement de la 
20 forme suivante : 

Smart/loader?AID=xxx&ByteCode=yyy&Signature=zzz (5), 
Dans laquelle "xxx" est Tentete 70 ("2001" dans Texemple de la 
figure 9), "yyy" est le "Byte Code" 71 ("0123456789ABCDEF" dans Texemple 
de la figure 9) et "zzz" la signature §lectronique 71 ("0123456789ABCDEF" 
25 dans Texemple de la figure 9). Les trois parties du fichier de chargement sont 
done bien inserees dans trois champs du formulaire "HTML" 8, sous forme 
concatenee. 

Le chargement d'une "applet" particuliere identifiee par I'entete 70 a 
lieu a ce moment. 

30 Enfin, lors d'une quatrieme etape un code de retour est transmis de 

la partie IL a la partie OL, toujours par mise en oeuvre de sessions entre 
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agents apparies. II s'agit en general d'un simple acquittement ou, si 
Toperation ne s'est pas realisee correctement d'un code d'erreur. Dans ce 
dernier cas, il est necessaire de renouveler les etapes 1 & 4. 

Comme solution alternative, il est possible d'utiliser la methode 

5 "POST" precitee. Pour fixer les idees, la figure 10 illustre un exemple d'un tel 
formulaire reference 8\ On retrouve diverses zones de texte et de graphique 
80, une zone d'affichage de I'entete 70 et une zone d'affichage de la 
signature electronique 72, ainsi que des boutons d'envoi "send" 81 et de 
remise a zero "Reset" 82. Ces elements jouent un role tout a fait similaire 

w aux elements de memes reference de la figure 9 et il est inutile de les re- 
decrire. Par contre, la zone d'affichage 71' ne visualise plus explicitement le 
"Byte Code", mais un repertoire ou un sous-repertoire ou le code de I* 
"applet" a charger est enregistre. En I'occurrence, cette zone pointe sur un 
fichier, appele arbitrairement "APPLET.BIN", enregistre sur une unite de 

15 stockage appelee "C", qui peut etre un disque dur present dans le terminal 1 . 
Un bouton supplemental de navigation "browse" 83 permet de balayer les 
divers (sous-)repertoires de ce disque et de selectionner un fichier particulier 
("APPLET.BIN"). 

La methode "POST" comme la methode "GET" est bien connue en 
20 soi, et il est inutile de la re-decrire en detail. Dans le cadre precis de 
I'invention, r "applet" correspondant au fichier "APPLET.BIN" est chargee, a 
partir de I'unite "C", de maniere similaire a ce qui a ete decrit pour la 
methode "GET". 

On va maintenant decrire un deuxieme exemple de chargement 
25 d' "applet" dans la carte a puce 2a. 

II est egalement possible d'enchainer plusieurs formulaires lors du 
chargement. A la place d'un simple statut (acquittement ou code d'erreur 
dans le premier exemple decrite en regard de la figure 8), le retour de la 
partie IL contient alors un nouveau formulaire. Ainsi, des sequences 
30 dynamiques d'echanges entre les parties OL et IL peuvent etre realisees. 
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Par exemple, apres analyse du fichier de chargement, la partie IL 
peut demander une autorisation (c'est-a-dire une signature electronique) 
supplementaire, par exemple celle d'une instance gouvernementale. Elle 
renvoie alors a la OL un formulaire qui peut avoir typiquement la structure 
"HTML" suivante (6) : 



10 



<TITLE>Authorisation form </TITLE> 

<FORM ACTION="http://@carte:8080/cgi-smart/loader"> 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENGTH="8">Signature 

</FORM> 



dans iaquelle "Authorisation form", entre les balises "HTLM" denommees 
"<TITLE>" et </TITLE>, represente le titre (arbitraire) du formulaire, "(©carte" 
la traduction litterale de I'adresse URL de rebouclage de la relation (1) et 
15 8080 le numero de port, la ligne de code : 

<INPUT TYPE="text" NAME="GouvSignature" MAXLENTH="8">Signature 
(7) 

requiert I'entree d'une variable appelee arbitrairement "Signature", en mode 

texte, de longueur maximale 8 octets, et </FORM> est la balise "HTML" 
20 indiquant la fin du code de formulaire. 

Le processus complet comprend alors deux etapes supplementaires 

avant I'etape finale d'acquittement ou de code d'erreur, soit six etapes, 

comme illustre par la figure 1 1 . 

De fagon plus generate, le nombre d'allers et retours peut d6pendre 
25 de parametres figurant dans Tun ou Tautre des formulaires echanges entre la 

carte a puce et la partie OL des programmes de chargement. 

Jusqu'a ce point, la localisation de la partie OL n'a pas ete precisee 

expressement. Outre le fait que le procede rend, a priori, compatible OL et 

IL, il permet aussi une tres grande souplesse pr§cisement quant a cette 
30 localisation, etant entendu que la partie IL est stockee dans la carte a puce 

2a comme formant Tune des applications presente dans cette carte a puce. 

Le procede selon Tinvention presente notamment Tavantage supplementaire 
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de ne plus exiger une proximity physique entre les deux parties OL et IL, 
puisqu'elles ne sont plus tributaires du protocole de communication ISO 
7816, les echanges entre ces deux portions de logiciel mettant en oeuvre le 
protocole de communication Internet TCP/IP. 
5 Aussi, la partie OL, ainsi que les donnees proprement dites de 

I' "applet" a charger sur la carte a puce 2a peuvent etre stockees soit en 
local, soit dans un site eloigne. Dans tous les cas cependant, les echanges 
entre ces deux parties mettent en oeuvre, comme il vient d'etre rappele, un 
protocole de communication "TCP/IP" et le chargement d'une "applet" se 
w deroule comme il a ete rappele precedemment grace aux fonctions de 
serveur/client "WEB" et "CGI" offertes par la carte a puce 2a. 

On va decrire maintenant, par reference aux figures 12A a 12G, les 
principales architectures pouvant etre mises en ceuvre dans le cadre de 
I'invention. 

*5 La figure 12 A illustre une architecture de systeme selon laquelle la 

partie OL est stockee en local sur le terminal 1 . Celui-ci est connecte a un 
serveur eloigne 4, via le reseau Internet Rl. Les donnees de I' "applet" a 
charger dans la carte a puce 2a, referencees Da, sont stockees sur ce 
serveur 4. Une requete "HTTP" permet de les transferer vers la carte a puce 

20 2a, via le terminal 1 (et un lecteur de carte a puce non represente), par mise 
en ceuvre du protocole de communication Internet "TCP/IP". 

Dans I'architecture de systeme representee sur la figure 12B, la 
partie de programme de chargement OL et les donnees Da sont stockees 
localement dans le terminal 1 . La connexion du terminal 1 au reseau Internet 

25 Rl est optionnelle. Pour le moins, elle n'est pas requise pour le chargement 
d'une "applet" selon les etapes du precede de I'invention. Cette connexion a 
ete representee en traits pointilles. Le terminal peut done etre autonome. 

Dans I'architecture de systeme representee sur la figure 12C, la 
partie de programme de chargement OL et les donnees Da sont stockees 

30 dans un serveur distant 4. Les communications entre le serveur 4 et la carte 
a puce 2a, via le reseau Internet Rl, le terminal 1 et le lecteur de carte a 
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puce (non represents) s'effectue par des requetes "HTTP", et mise en oeuvre 
du protocoie "TCP/IP". 

L'architecture de systeme representee sur la figure 12D est similaire 
a celle de la figure 12C. La seule difference est que la partie de programme 
5 de chargement OL est stockee dans un premier serveur distant, reference 
4a, et que les donnees Da, sont stockees dans un second serveur distant, 
reference 4b. 

Dans I'architecture de la figure 12E, la partie du programme de 
chargement, referencee ici OL', est constitute par un composant du 
10 navigateur 10 lui-meme. II s'agit avantageusement d'une "applet" integree 
dans ce navigateur. Le type d'.entree a utiliser dans ce cas est "file" (fichier). 

De fagon avantageuse egalement, les donnees Da, de P "applet" a 
charger sur la carte a puce 2a, peuvent etre stockees sur un support 
d'enregistrement de donnees externe 9, par exemple une disquette comme 
15 illustre par la figure 12E. Naturellement d'autres supports sont utilisables : 
CedeROM, bande magnetique, etc. 

Si on utilise la methode "POST" precitee, il suffit de specifier la lettre 
de I'unite de stockage, par exemple "A" pour la disquette 9, un eventuel 
chemin (repertoire, sous-repertoires) et le nom du fichier a charger. Pour 
20 fixer les idees, le chemin complet pourrait etre typiquement : 

A:\APPLET.BIN (8) 
Du fait de la fonction serveur/client "WEB" offerte par la carte a 
puce 2a, selon une des caracteristiques du procede de ('invention, le 
navigateur 10 est a meme, contrairement a Tart connu, de communiquer 
25 directement avec cette derniere, comme il Ta et6 montre en regard des 
figures 2 a 4. Les communications s^ffectuent par Touverture de sessions 
entre agents apparies. 

Larchitecture de systeme illustree par la figure 12F est une variante 
de ('architecture de la figure 12E. Selon cette variante, la partie de 
30 programme de chargement OL est stockee dans la carte a puce 2a elle- 
meme, sous forme d'une "applet" en langage "JAVA". Par une requete 
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"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1 , 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Une fois la partie OL chargee, les 
etapes ulterieures sont communes au cas precedent. Les donnees Da 
5 peuvent egalement etre stockees sur un support externe, par exemple une 
disquette 8. 

Uarchitecture de systeme de la figure. 12G est une variante de celle 
de la figure 12F. La seule difference est que la partie de programme de 
chargement OL est stockee sur un serveur eloigne 4, sous forme d'une 
10 "applet" en langage "JAVA". Comme precedemment, par une requete 
"HTTP", cette "applet" peut etre chargee dynamiquement sur le terminal 1, 
en OL". Ce chargement s'effectue a I'aide de requetes posees par le 
navigateur 10, lors d'etapes preliminaires. Les autres etapes sont communes 
au cas precedent. 

15 II est clair que d'autres variantes d f architecture peuvent etre mises 

en ceuvre sans sortir du cadre de I'invention. II est notamment possible de 
charger les donnees Da dans le terminal 1 a partir de diverses sources : par 
exemple a partir d'un autre systeme informatique, connecte au terminal 1 par 
un reseau local ou par tous autres moyens telematiques. 

20 A la lecture de ce qui precede, on constate aisement que I'invention 

atteint bien les buts qu'elle s'est fixes. 

La mise en ceuvre du chargement d'une "applet" dans une carte a 
puce par I'interface "CGI" d'un serveur "WEB" loge dans cette carte a puce 
presente notamment les avantages suivants : 

25 ^utilisation de formulaires en langage "HTML" standardise le 

chargement et rend les parties de programmes de chargement OL et IL a 
priori compatibles. En effet, comme il a ete montre, c'est la partie IL situee 
dans la carte a puce qui decrit, dans les champs du ou des formulaire(s) 
renvoye(s), le parametrage de chargement auquel il s'attend. 
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Par ailleurs, ce mecanisme de communication entre les parties de 
programme de chargement OL et IL permet de gerer simplement des 
sequences d'echanges dynamiques lors du chargement. 

L'utilisation des protocoles Internet "HTTP" et "TCP/IP" pour les 
5 echanges entre les parties de programme de chargement OL et IL permet de 
les separer physiquemenL Seul un routage de paquets "IP" est necessaire 
sur le terminal. Le chargement peut alors se faire dans un lecteur carte a 
puce banalise, puisque Ton conserve le protocole de communication ISO 
7816. Le terminal peut etre un simple micro-ordinateur standard connecte & 
w Internet. 

Sielon un aspect avantageux egalement du procede de invention, 
les^applications stockees dans la carte a puce restent standards, et done 
n'ont pas a etre re-ecrites. La carte a puce et le terminal eux-memes ne 
n^cessitent que peu de modifications pour pouvoir accommoder le procede 
15 de ['invention : ces dernieres se resument a I'implantation, dans ces deux 
unites, d'une couche logicielle de protocole de communication qui a 6te 
appelee specifique, couche logicielle incluant des agents intelligents. 

Alternativement, la partie de programme de chargement OL peut 
etre chargee dynamiquement sur le terminal, au travers la carte, a partir de 
20 celle-ci ou d f un serveur "HTTP" 6loigne. 

Un simple navigateur Internet peut etre utilise comme programme 
de chargement OL. 

II doit etre clair cependant que I'invention n f est pas limitee aux seuls 
exemples de realisations explicitement decrits, notamment en relation avec 
25 les figures 2 a 12G. 

D ( autre part, en lieu et place du langage "HTML", d'autres langages 
similaires, adaptes aux protocoles de communication de type "Internet" 
peuvent etre utilises, notamment le langage "XML". 

L'invention concerne aussi un procede de chargement d'une piece 
30 de logiciel dans une carte a puce a partir d'un terminal connecte a ladite 
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carte a puce par Pintermediaire d'un lecteur de carte a puce permettant des 
communications selon un premier protocole determine, le terminal et la carte 
a puce comprenant des moyens de traitement d'information et des moyens 
de stockage d'information, ledit chargement s'effectuant par la mise en 
5 oeuvre et la cooperation de premier et second programmes de chargement, 
ledit second programme de chargement etant stocke dans les moyens de 
stockage d'information de ladite carte a puce, caracterise en ce qu'il 
comprend au moins les phases suivantes : 

a/ une premiere phase preliminaire consistant a implanter, dans les 
10 moyens de stockage d'information de ladite carte a puce (2a), une 

premiere piece de logiciel (23a), formant une couche protocolaire de 
communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans les 
moyens de stockage d'information dudit terminal (1), une seconde 
15 piece de logiciel (13), formant une couche protocolaire de 

communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) 
comprennent en outre au moins une paire de premieres entites logicielles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant Tune 

20 avec Pautre, grace auxdits moyens de traitement d'information du terminal et 
de la carte a puce, de maniere a permettre Petablissement d'une session 
d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) off re la 
fonctionnalite d'un client/serveur "WEB" ; 

25 en ce qu'il comprend une troisieme phase preliminaire consistant a 

implanter dans les moyens de stockage d'information de ladite carte a puce 
(2a) au moins une deuxieme entite logicielle (>47S t - ATS n ), apte a interpreter 
une suite destructions et a la traduire en une suite d'ordres, de maniere a 
cooperer avec ladite seconde piece de logiciel specifique (23a) pour que 

30 ladite carte a puce offre une fonctionnalite d'interface passerelle dite "CGI", 
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la dite carte a puce comprenant au moins une desdites suites destructions 
associee au dit second programme de chargement (IL) ; 
et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d'une premiere session d'echanges de donnees 
5 entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 

auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la transmission d'une requete pour que ledit premier 
programme de chargement (OL) recupere des donnees de 
parametrage de chargement fournies par ledit second programme de 
w chargement (IL) ; 

21 ouverture d'une deuxieme session d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) grace 
auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour transmettre lesdites donnees de parametrage de 
15 chargement au dit premier programme de chargement (OL), lesdites 

donnees de parametrage comportant une reference aux dites 
instructions associees au dit second programme de chargement (IL) ; 
et 

3/ ouverture d'une troisieme session d'echanges de donnees 
20 entre au moins ledit terminal (1) et ladite carte a puce (2a) grace 

auxdits moyens de traitement d'information du terminal et de la carte a 
puce, pour la soumission d'un fichier de chargement (7)' prenant en 
compte lesdites donnees de parametrage de chargement, ledit fichier 
comprenant des donnees (70, 71, 72) associees a ladite piece de 
25 logiciel a charger (Da) ; interpretation de ladite suite ^instructions 

associee au dit second programme de chargement (IL), par mise en 
oeuvre de ladite fonctionnalite "CGI", de maniere a generer une suite 
d'ordres transmise au dit second programme de chargement (IL), a 
executer ce programme (IL) et a obtenir ledit dechargement de ladite 
30 piece de logiciel (Da). 
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REVENDICATIONS 

1. Procede de chargement d'une piece de logiciel dans une carte a puce a 
partir d'un terminal connecte a ladite carte a puce par Hntermediaire d*un 
5 lecteur de carte a puce permettant des communications selon un premier 
protocole determine, ledit chargement s f effectuant par la mise en ceuvre 
et la cooperation de premier et second programmes de chargement, ledit 
second programme de chargement etant stocke dans ladite carte a puce, 
caracterise en ce qu'il comprend au moins les phases suivantes : 

™ a/ une premiere phase preliminaire consistant a implanter, dans 

ladite carte a puce (2a), une premiere piece de logiciel (23a), formant 
une couche protocolaire de communication specifique ; 

b/ une deuxieme phase preliminaire consistant a implanter, dans 
ledit terminal (1), une seconde piece de logiciel (13), formant une 
15 couche protocolaire de communication specifique ; 

en ce que lesdites premiere et seconde pieces de logiciel (13, 23a) * 
comprennent en outre au moins une paire de premieres entites logicieiles 
appariees (132, 232a), chacune desdites entites (132, 232a) cooperant I'une 
avec I'autre de maniere a permettre Tetablissement d'une session 
20 d'echanges de donnees bidirectionnels entre au moins ledit terminal (1) et 
ladite carte a puce (2a), de maniere a ce que ladite carte a puce (2a) offre la 
fonctionnalite d'un client/serveur "WEB" ; 

en ce qu'il comprend une troisieme phase preliminaire consistant a 
implanter dans ladite carte a puce (2a) au moins une deuxieme entite 
25 logicielle (ATS, - >A7"S n ), apte a interpreter une suite destructions et a la 
traduire en une suite d'ordres, de maniere a cooperer avec ladite seconde 
piece de logiciel specifique (23a) pour que ladite carte a puce offre une 
fonctionnalite d'interface passerelle dite "CGI", la dite carte a puce 
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comprenant aii moins une desdites suites destructions associee au dit 
second programme de chargement (IL) ; 

et en ce qu'il comprend au moins les etapes suivantes : 

1/ ouverture d'une premiere session d'echanges de donnees 
5 entre au moins ledit terminal (1) et ladite carte a puce (2a), pour la 

transmission d'une requete pour que ledit premier programme de 
chargement (OL) recupere des donnees de parametrage de 
chargement fournies par ledit second programme de chargement (IL) ; 
21 ouverture d'une deuxieme session d'echanges de donnees 

10 entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

transmettre lesdites donnees de parametrage de chargement au dit 
premier programme de chargement (OL), lesdites donnees de 
parametrage comportant une reference aux dites instructions associees 
au dit second programme de chargement (IL) ; et 

15 3/ ouverture d'une troisieme session d'echanges de donnees 

entre au moins ledit terminal (1) et ladite carte a puce (2a), pour la 
soumission d'un fichier de chargement (7) prenant en compte lesdites 
donnees de parametrage de chargement, ledit fichier comprenant des 
donnees (70, 71, 72) associees a ladite piece de logiciel a charger 

20 {Da) ; interpretation de ladite suite destructions associee au dit second 

programme de chargement (IL), par mise en oeuvre de ladite 
fonctionnalite "CGI", de maniere a generer une suite d'ordres transmise 
au dit second programme de chargement (IL), a executer ce 
programme (IL) et a obtenir ledit dechargement de ladite piece de 

25 logiciel (Da). 

2. Procede selon la revendication 1 , caracterise en ce que ledit lecteur de 
carte a puce (3) et ladite carte a puce (2a) comprennent des premiere et 
deuxieme piles protocolaires pour lesdites transmissions de donnees 
selon ledit premier protocole determine, definies par la norme ISO 7816, 
30 chacune comprenant au moins des couches protocolaires de 
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communication logicielles (101, 200a), dites basses, de maniere a 
permettre lesdits echanges de donnees entre ladite carte a puce (2a) et 
ledit terminal (1), ces couches formant interface avec lesdites premiere 
(13) et seconde (23a) pieces de logiciel specif ique formant lesdites 
couches protocolaires de communication specifiques, respectivement, et 
en ce que ces pieces de logiciel (13, 23a) comprennent chacune deux 
entites supplementaires constitutes d'un module de transfert de donnees 
(130,230a), formant interface avec lesdites couches basses (101, 200a) 
des premiere et deuxieme piles protocolaires, et d'un module de gestion 
(131 , 231a), et en ce que lesdites premieres entites de chaque paire sont 
constitutes de modules logiciels, dits agents intelligents (132, 232a1) 
etablissant lesdites sessions. 

3. Procede selon la revendication 2, caracttrist en ce que ladite suite 
destructions a interpreter associee au dit second programme (IL) de 

15 ! dechargement est constitute par un script et en ce que ladite deuxieme 
entite logicielle est constitute par un module logiciel dit agent intelligent 
traducteur de script (ATS, - ATS n ) fournissant des ordres comprehensibles 
par ledit second programme de chargement (OL). 

4. Procede selon la revendication 3, caracttrist en ce que ladite premitre 
20 ttape comprend remission d'une requete de type dit "HTTP" selon un 

protocole de type Internet par adressage d'une page dtterminte en 
langage "HTML" contenant lesdites donntes de paramttrage, ladite 
adresse ttant une adresse de type "URL" de rebouclage sur ladite carte a 
puce (2a). 

25 5. Proctdt selon la revendication 4, caracttrist en ce que ladite deuxieme 
ttape comprend renvoi par ladite carte a puce (2a) d'un formuiaire (8, 8') 
en langage "HTML" et en ce que ledit formuiaire (8, 8') comprend au 
moins une adresse de type dit "URL" de rebouclage sur ladite carte a 
puce (2a) et un chemin menant a un rtpertoire determine contenant ledit 
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script associe au dit second programme de chargement (IL), de maniere a 
ce que ce dit premier programme de chargement (OL) recupere les dites 
donnees de parametrage. 

6- Procede selon la revendication 5, caracterise en ce que ladite troisieme 
5 6tape comprend renvoi d'une requete de type dit "HTTP" a ladite adresse 
"URL", designant ledit repertoire contenant ledit script associe au dit 
second programme de chargement (IL), ladite requete comprenant 
lesdites donnees representant ladite piece de logiciel a charger (Da), 
I'interpretation dudit script et Texecution dudit second programme de 
10 chargement (OL), de maniere a obtenir ledit chargement de la dite piece 
de logiciel (Da). 

7. Procede selon la revendication 6, caracterise en ce que ladite piece de 
logiciel (Da) est une appliquette ecrite en langage "JAVA" (marque 
deposee). 

15 8. Procede selon la revendication 7, caracterise en ce que ledit fichier de 
chargement (7) est incorpore dans ledit formulaire (8, 8') et comprend une 
entete (70) identifiant ladite appliquette, des donnees (71) et au moins 
une signature electronique (72) obtenue a partir du chiffrement desdites 
donnees. 

20 9. Procede selon la revendication 8, caracterise en ce qu'i! comprend au 
moins une premiere etape supplemental, realisee apres ladite troisieme 
etape, et en ce que cette premiere etape supplemental consiste en 
Touverture premiere session supplemental d'echanges de donnees 
entre ladite carte a puce (2a) et au moins ledit terminal (1) pour 

25 transmettre un code predetermine regu par ledit premier programme de 
chargement (OL). 
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10.Proc6d6 selon la revendication 9, caracterise en ce que ledit code 
predetermine consiste en un acquittement lorsque lesdites trois premieres 
etapes se sont deroulees correctement ou un code d'erreur dans le cas 
contraire. 

5 H.Procede selon la revendication 10, caracterise en ce qu'il comprend au 
moins deux etapes supplementaires, realisees apres ladite troisieme 
etape, comprenant Touverture de sessions d'echanges de donn6es 
bidirectionnels entre ladite carte a puce (2a) et au moins ledit terminal (1) 
pour la transmission d'un formulaire supplementaire requerant la 
w soumission de donnees supplementaires. 

12. Procede selon la revendication 11, caracterise en ce que lesdites 
donnees supplementaires comprennent une signature electronique 
supplementaire. 

13. Procede selon la revendication 12, caracterise en ce que ledit terminal 
15 etant connecte a au moins un serveur eloigne (4) via un reseau de type 

Internet (Rl) et par la mise en oeuvre de protocole de communication de 
type Internet, un desdits agents intelligents (132) est associe a un attribut 
dit de "reseau" permettant des communications avec ledit reseau Internet 
(Rl) et en ce que ledit premier programme de chargement (OL) est stocke 
20 sur Tun desdits serveurs eloignes (4, 4a). 

14. Proc6de selon la revendication 13, caracterise en ce que, ledit terminal 
(1) comprenant un navigateur de type "WEB" (10), ledit premier 
programme de chargement (OU) est constitue par un composant logiciel 
dudit navigateur "WEB" (10). 

25 15.Procede selon la revendication 14, caracterise en ce que ledit composant 
logiciel (OL") est obtenu par une etape initiale de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans ladite 
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carte a puce (2a), ledit chargement etant obtenu par remission d'une 
requete de type "HTTP", avec un adressage de type "URL" de ladite carte 
a puce (2a). 

16.Procede selon la revendication 17, caracterise en ce que ledit composant 
5 logiciel (OL") est obtenu par une etape initiate de chargement dynamique 
d'une appliquette (OL) ecrite en langage "JAVA" et stockee dans un 
desdits serveurs eloignes (4), ledit chargement etant obtenu par remission 
d'une requete de type "HTTP", avec un adressage de type "URL" dudit 
serveur eloigne (4). 



WO 01/59563 



PCT/FR01/00393 



1/10 



0L . — • . 

' — "OFF-LOADER" j 

1 



, TERMINAL 


] "IN-LOADER" \ 


LECTEUR CARTE 


APDU 


CARTE A PUCE , 


•4 



IL 



FIG.1A 

ART ANTERIEUR 



2l 



ECRAN 



SERVEUR 
WEB 



NAVI6ATEUR 
WEB 



¥1 
Hi 



^10 12 
OL— 1= 1 



MODEM 



^ ^Off-Loader 
TERMINAL 



20 



CARTE 
A PUCE 



P 



LECTEUR 



6b 




RESEAU 

INTERNET 



6a 



Rl 



FIG.1B 

ART ANTERIEUR 



WO 01/59563 



PCT/FR01/00393 



2/10 

Application) ( Application) 




201 FIG.iC 

ART ANTERIEUR 



2a 



\ 



NAVIGATEUR 
WEB 



10 



TERMINAL 



100 

_L_ 




Multiptexeur 
de paquets 

u li- 'J 



i 



TCP/IP 



-i 



11 



7816-4 
"APDU" 



101 



Acces reseau 
OSI1-OSI2 



102 



7816-3 



I 

| LECTEURj 




Gestionnaire 
"APDU" 



7816-3 



200a 




FIG.4 



WO 01/59563 



PCT/FR01/00393 




WO 01/59563 



PCI7FR01/00393 



4/10 




Session "S-Agent" 

FIG.3 



OL 



CGI 



SC 



["OFF-LOADER" (OL)|- 



http 




TERMINAL 



LECTEUR 



1 1 I ILs 

ii y-^ 

II 

IserveurJ ] IL 

http 1 1 script 

II 
II 

I II I 



APDU 



CARTE A PUCE 



2a 



FIG.6 



70 



1 



71 



4 



72 



4 



EN TETE 



"BYTE CODE" 



FIG.7 



SIGNATURE 



WO01/595d3 



PCT/FR01/00393 




WO 01/59563 



PCT/FR01/00393 



6/10 



Ecran1 ]T 



TERMINAL 

^10 



NAVIGATEUR 



GET(obtenir"download.htmr') 



FORMULAIRE 



GET(soumettre fichier de chargemennt) 



ACQUITTEMENT/ERREUR 



2a 



3- 



OL 



CARTE 
A PUCE 



r 1 

l"IN-LOADER"l 

l — r 

IL 7 



I "OFF-LOADER"! 
L J 



FI6.8 



Ecran| )T 



A' 



GETlobfenir-download.html") 



2a 



FORMULAIRE 



TERMINAL 



-10 



NAVIGATEUR 



GETtsoumeHre fichier de chargemennt) 



FORMULAIRE 



GETIsoumefr. autorisation gouvernemenrale) 



ACQUITTEMENT/ERREUR 



CARTE 
A PUCE 



r 1 

l"IN-LOAOER"l 



OL 



I "OFF-LOADER" 
L J 



FIG.11 



WO 01/59563 



PCT/FR01/00393 



7/10 



70 



71 



72 



Get Method 



ALD 



ROOT 



Syte Code 



7=P 



.80 

L 



0123456789ABCDEF 



Signature 



"Z. 



0123I56789ABCDEF I 



Send | Resetj 



81 



y 82 



FIG.9 



HE 



70 



7V- 
72 



POST Method 



ALD 



.80 



2001 



Byte Code 



_ \ APPLET BIN / 



Sign ature ^ 

- — tQ123^56789ABCDEF I 



Send 



81 



Reset 
82 



8' 



I .Browse.... I 



83 



FIG.10 



WO 01/59563 



PCT/FR01/00393 



8/10 




INTERNET—' TCP/IP 




FIG.12A 



C J OL 

] SERVEURj T cp/|p RU 
i r* 7 —1 



RESEAU ) 
INTERNET^ TCP/IP 




FIG.12B 



WO 01/59563 PCT/FR01/00393 



9/10 




INTERNET—^ TCP/IP 




FIG.12C 




WO 01/59563 



PCT/FR01/00393 



SERVEURj /_ 



10/10 10 

ou 



/ 

RESEAU 1 
INTERNETS TCP/IP 



FIG.12E 




IDISQUETTE 
DONNEES 



f. i^TCP/iP R, ji 



|serveur| 



RESEAU ) 
INTERNET^ TCP/IP 



FIG.12F 

iSERVEUR j TCP/ IP R h 



OL 



/ 



RESEAU L Z 
INTERNET. - 



FIG.12G 




DONNEES 



INTERNATIONAL SEARCH REPORT 



tnte> .onal Application No 

PCT/FR 01/00393 



A. CLASSIFICATION OF SUBJECT MATTER ■ 

IPC 7 G06F9/445 H04L29/06 



According lo Inlemalional Palenl Classification (IPC) or lo both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (ctassitication system followed by classification symbols) 

IPC 7 G06F H04L 



Documentation searched other than minimum documentation to Ihe extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name ot data base and. where practical, search terms used) 

EPO-Internal 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ■» Citation ot document, with indication, where appropriate, of Ihe relevant passages 



Relevant to claim No. 



WO 98 57474 A (GEMPLUS CARD INT jMARTINEAU 
PHILIPPE (FR); MERRIEN LIONEL (US); SI) 
17 December 1998 (1998-12-17) 
abstract; claims 1,3,5,6; figure 2 

WO 98 17029 A (TELIA AB) 
23 April 1998 (1998-04-23) 
the whole document 



1,2 



1,2 



□ 



Further documents are listed in the continuation of box C. 



j)( I Patent family members are listed in annex. 



° Special categories of cited documents : 

'A' document defining the generaJ state of the art which is not 

considered to be of particular relevance 
*E' earlier document but published on or after the international 

filing dale 

"L* document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

'O* document referring to an oral disclosure, use. exhibition or 
other means 

•p* document published prior to the international filing date but 
later than the priority date claimed 



*T" later document published after the international filing date 
or priority date and not in conflict with the application bul 
cited to understand the principle or theory underlying the 
invention 

'X" document of particular relevance: Ihe claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

•Y' document of particular relevance; Ihe claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such c 
menls. such combination being obvious to a person s 
in ihe art. 

'&* document member of the same patent family 



Date ot the actual completion ol the international search 



13 June 2001 



Date of mailing of the international search report 



22/06/2001 



Name and mailing address ot the ISA 

European Patent Office. P.B. 5818 Patentiaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epont. 
Fax: (+31-70) 340-3016 



Authorized officer 



Kingma, Y 



Form PCT7ISATC10 {second sheet) (July 1992) 



INTERNATIONAL SEARCH REPORT 

Information on patent family members 


Intei ,onal Application No 

PCT/FR 01/00393 


Patent document 
cited in search report 


Publication 
date 


Patent family 
member(s) 


Publication 
date 



WO 9857474 A 17-12-1998 AU 8113798 A 30-12-1998 

CN 1284230 T 14-02-2001 

EP 1050145 A 08-11-2000 

TW 378308 B 01-01-2000 

ZA 9805151 A 13-04-1999 



W0 9817029 A 23-04-1998 SE 506628 C 19-01-1998 

EP 0932956 A 04-08-1999 

NO 991756 A 14-06-1999 

SE 9603825 A 19-01-1998 



Form PCT/I&V210 (palent lamily ami) (July 1962) 



RAPPORT DE RECHERCHE INTERNATIONALE 



Den .e Inter natiorvaJe No 

PCT/FR 01/00393 



A. CLASSEMENT DE L OBJET DE LA DEMANDE , 

CIB 7 G06F9/445 H04L29/06 



Selon la dassiltcalion Internationale des brevets (CIB) ou a la loisselon la classification nationale el la CIB 



B. DOMAINES SUR LESOUELS LA RECHERCHE A PORTE 



Documentation minimale consullee (systeme de classilicaUon suivi des symboles de classement) 

CIB 7 G06F H04L 



Documentation consutlee autre que la documentation minimale dans la mesure oil ces documents relevenl des domaines sur lesquels a pone la recherche 



Base de donnees electronique consullee au cours de ta recherche international (nom de la base de donnees. et si realisable, lermes de recherche, utilises) 

EPO-Internal 



C. DOCUMENTS CONSIDERES COMME PERTINENTS 



Categorie " Identification des documents dies, avec le cas echeanl. I'indication des passages pertinents 



no. des revendicattons visees 



WO 98 57474 A (GEHPLUS CARD INT ; MARTI NEAU 
PHILIPPE (FR); MERRIEN LIONEL (US); SI) 
17 decembre 1998 (1998-12-17) 
abrege; revendications 1,3,5,6; figure 2 

WO 98 17029 A (TELIA AB) 
23 avril 1998 (1998-04-23) 
le document en entier 



1,2 



1,2 



| J Voir la suite du cadre C pour ta tin de la lisle des documents 



Les documents de families de brevets sont indiques en annexe 



• Categories speciates de documents cites: 

"A* document definissant Fetal general de la technique, non 

considere comme particulieremerd pertinent 
'E' document anterieur, mats publie a la date de depot international 

ou apres cette date 
V document pouvant Jeter un doute sur une revendi cation de 

priorite ou cite pour determiner ta date de publication dune 

autre citation ou pour une raison spedale (telle qulndiquee) 
'O* document se referanl a une divulgation orale. a un usage, a 

une exposition ou lous autres moyens 
'P* document publie avant la date de depot international, mais 

posterieuremenl a la date de pnorite revendiquee 



"T* document ulterieur publie apres la date de depot international ou la 
date de prior ile et n'apparienenant pas a retai de la 
technique pertinent, mais cite pour comprendre le principe 
ou la theorie constituant la base de f invent ion 

'X" document particulierement pertinent: rinven lion revendiquee ne peut 
etre consideree comme nouveKe ou comme impliquant une actrvBe 
inventive par rapport au document considere isolemeni 

*Y* document particulierement pertinent; rinven lion revendiquee 
ne peul etre consideree comme impliquant une adivite inventive 
lorsque le document est assode a un ou plusieurs autres 
documents de meme nature, cette combinaison etant evidenie 
pour une personne du metier 

'&* document qui fait parte de la meme famille de brevets 



Dale a laqueDe la recherche Internationale a ete effedivement achevee 



13 juin 2001 



Date d'expedition du present rapport de recherche Internationale 



22/06/2001 



Nom et adresse po stale de radministralion chargee de la recherche rntemationale 
Office Europeen des Brevets. P.B. 5618 Palentlaan 2 
NL * 2280 HV Rijswijk 
Tel. (+31-70) 340-2040. Tx. 31 651 epo nl, 
Fax (+31-70) 340-3016 



Fonctk>nnaire autorise 



Klngma, Y 



Formulairo PCT/ISA/210 (deuxieme teuiBe) (ruitet 1992) 



RAPPORT DE RECHERCHE INTERNATIONALE 

Re ns eigne merits retatifs aux membresde families de brevets 



Den. .e Internationale No 

PCT/FR 01/00393 



Document brevet cite 
au rapport de recherche 



Datede 
publication 



Membrefs) de la 
famine de brevet(s) 



Datede 
publication 



WO 9857474 



17-12-1998 



WO 9817029 



23-04-1998 



AU 
CN 
EP 
TW 
ZA 



SE 
EP 
NO 
SE 



8113798 A 
1284230 T 
1050145 A 
378308 B 
9805151 A 



506628 C 
0932956 A 

991756 A 
9603825 A 



30-12-1998 
14-02-2001 
08-11-2000 
01-01-2000 
13-04-1999 



19-01-1998 
04-08-1999 
14-06-1999 
19-01-1998 



Fofmutoite PCT/lSA/210 (amexs families ds brevets) (juitet 1992) 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



